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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present specification shows QoS signalling flows for resource reservation to provide end-to-end QoS. The flows are 
used as bases of developing QoS related protocol descriptions for new and existing specifications. 

The relationship between SIP/SDP session level and the bearer level (RSVP and GPRS) in flows is described in 
3GPP TS 24.228 [2]. The present specification adds detailed flows of Service Based Local Policy (SBLP) procedures 
over the Go interface and their relationship with the bearer level signalling flows over the Gn interface. 

The present specification also describes the mapping of QoS parameters among SDP, UMTS QoS parameters, and QoS 
authorization parameters. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 24.228: "Signalhng flows for the IP multimedia call control based on SIP and SDP; 

Stage 3". 

[3] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3". 

[4] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

[5] 3GPP TS 26.234: "End-to-end transparent streaming service; Protocols and codecs". 

[6] 3GPP TS 26.236: "Packet switched conversational multimedia applications; Transport protocols". 

[7] 3GPP TS 29.207: "Policy control over Go interface". 

[8] 3GPP TS 23.107: "Quality of Service (QoS) concept and architecture". 

[9] IETF RFC 2327: "SDP: Session Description Protocol". 

[10] IETF RFC 3556: "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control 

Protocol (RTCP) Bandwidth". 

[II] IETF RFC 3264: "An Offer/ Answer model with the Session Description Protocol (SDP)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply: 

QoS Class: Class of QoS used in Authorized IP QoS parameters as specified in 3GPP TS 29.207 [7]. 
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3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply: 



COPS 

DEC 

DRQ 

IMS 

PDF 

REQ 

RPT 

SBLP 



Common Open Policy Service protocol 
COPS DECision message 
COPS Delete ReQuest state message 
IP Multimedia CN Subsystem 
Policy Decision Function 
COPS REQuest message 
COPS RePorT state message 
Service Based Local Policy 



4 Authorize QoS resources 

4.1 Authorize QoS resources at originating PDF 

This clause covers the Authorize QoS resources procedure at the originating PDF. 



UE 



GGSN 



SDP 



SDP 



P-CSCF 
PDF 



1. Define down-link 
connection info 



SDP 
SDP 



2. Define up-link 
connection info 



3. QoS authorisation 



1 . The P-CSCF(PDF) gets the SDP parameters defined by the originator and identifies the connection 
information needed (IP address of the down link IP flow(s), port numbers to be used etc.). 

2. The P-CSCF(PDF) gets the negotiated SDP parameters from the terminating side through SIP signalling 
interaction. The P-CSCF{PDF) identifies the connection information needed (IP address of the up-link 
media IP flow(s), port numbers to be used etc.). 

3. The P-CSCF(PDF) uses the SDP parameters in order to define the QoS resource authorisation. The PDF 
authorises every component negotiated for the session. The authorization shall be expressed in terms of 
IP QoS parameters. An authorization token is generated by the PDF and sent to the UE. 

Figure 4.1 : Authorize QoS resources at originating PDF 
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4.2 Authorize QoS resources at terminating PDF 

This clause covers the Authorize QoS resources procedure at the terminating PDF. 



P-CSCF 
PDF 



SDP » 



GGSN 



1. Define up-link 
connection info 



2. Define down-linl< 
connection info 



QoS authorisation 



UE 



SDP 
SDP 



SDP 



The P-CSCF(PDF) gets the SDP parameters defined by the originator and identifies the connection 
information needed (IP address of the up-link IP flow(s), port numbers to be used etc...)- An authorization 
token is generated by the PDF and sent to the UE. 

The P-CSCF(PDF) receives the negotiated SDP parameters from the UE. The P-CSCF(PDF) identifies the 
connection information needed (IP address of the down-link IP flow(s), port numbers to be used etc.). 
The P-CSCF(PDF) uses the SDP parameters in order to define the QoS resource authorisation. The PDF 
authorises every IP flow of a media component negotiated for the session. The authorization shall be 
expressed in terms of IP QoS parameters. 



Figure 4.2: Authorize QoS resources at terminating PDF 



5 Resource reservation flow with Service-based local 

policy 

This clause describes a resource reservation flow with service based local policy. The service based local policy is done 
via exchange of information through the Go interface. The Go interface allows the service based local policy and QoS 
interworking information to be requested by the GGSN from a PDF. 

Figure 5.1 presents the "Resource Reservation" procedure at PDP context activation to both the Mobile Originating 
(MO) side and Mobile Terminating (MT) side. 
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UE 



SGSN 



1 . Mapping of 
SDP parameters 
into UMTS QoS 



-2. Activate PDP Req. 



■10. Activate PDP Ace. 



GGSN 



-3. Create PDP Req. 



PDF 



-4. COPS REQ 



5. Process ^ 
authorization 
request 



-6. COPS DEC 



7. Policy 
Enforcement 



-9. Create PDP Res. 



-8. COPS RPT 



Figure 5.1 : Resource reservation flow with service based local policy 

1. Mapping from SDP to UMTS QoS parameters 

The UE uses the SDP parameters in order to define the UMTS QoS parameter needed to request a PDP context. The 
QoS parameter mapping mechanism is described in clause 7.2. 

2. GPRS: Activate PDP Context Request (UE to SGSN) 

The UE sends an Activate PDP Context Request message to the SGSN with the UMTS QoS parameters. The UE shall 
include binding information in the PDP context activation messages to associate the PDP context bearer with policy 
information. The authorization token is sent by the P-CSCF to the UE during SIP signalling. 

3. GPRS: Create PDP Context Request (SGSN to GGSN) 

The SGSN carries out the procedures identified in 3GPP TS 23.060 [4] related to the PDP context activation. 

4. COPS: REQ (GGSN to PDF) 

The GGSN receives the PDP context activation request with the binding information. The GGSN uses the authorisation 
token in order to localise the PDF. The GGSN sends a COPS REQ message to the PDF and includes the binding 
information. 

5. Process Resource Request (PDF) 

The PDF receives the information sent by the GGSN. The PDF identifies the multimedia session by using the binding 
information. The PDF performs an authorization decision. The PDF may include the gate enabling command as part of 
the authorisation decision, for instance to enable early media as described in 3GPP TS 29.207 [7] 

6. COPS: DEC (PDF to GGSN) 

The decision taken by the PDF is returned via the COPS DEC message. The DEC message includes the policy 
information to be used by the GGSN in order to perform the policy-based admission control. 
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7. Policy Enforcement (GGSN) 

The GGSN enforces the PDF poUcy decision on the IP flows based on the received authorization information from the 
PDF for the media components carried by the PDP context. 

8. COPS: RPT (GGSN to PDF) 

The GGSN sends COPS RPT message back to the PDF and reports its success or failure in carrying out the PDF 
decision. 

9. GPRS: Create PDP Context Response (GGSN to SGSN) 

The GGSN accepts the PDP context request based on the results of the authorisation policy decision enforcement. If the 
requested QoS parameters are not within the authorized QoS, the GGSN downgrades the requested UMTS QoS 
parameters. 

10. GPRS: Activate PDP Context Accept (SGSN to UE) 

The SGSN sends an Activate PDP Context Accept message to the UE indicating that the PDP context has been 
activated and that the QoS requirements have been authorized successfully for both downlink and uplink. 



6 Other flows over Go interface 

6.1 Approval of QoS commit 

Through Approval of QoS Commit the PDF makes a final decision to enable the allocated QoS resource for the 
authorized IP flows of the media component (s) if the QoS resources are not enabled at the time they are authorized by 
the PDF or if the media IP flow(s) previously placed on hold are resumed, i.e. the media IP flow(s) of the media 
component that was placed on hold at the time of the resource authorization or at a later stage is reactivated (with SDP 
direction sendrecv, sendonly, recvonly or none direction). 

The Approval of QoS Commit procedure is triggered by the P-CSCF receiving a 200 OK response to an INVITE 
request or a 200 OK response to an UPDATE request within a confirmed dialogue. When receiving those 200 OK 
responses, the PDF shall take the SDP direction attribute in the latest received SDP (either within the 200 OK or a 
previous SIP message) into account when deciding, which gates shall be opened: 

For a unidirectional SDP media component, the Approval of QoS Commit procedure shall not be triggered for 
the possible media IP flows in the opposite direction. 

For an inactive SDP media component, the Approval of QoS Commit procedure shall not be triggered for the 
media IP flows. 

Figure 6.1 is applicable to the Mobile Originating (MO) side and the Mobile Terminating (MT) side. 
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GGSN 



P-CSCF 
PDF 



1 . 200 OK 



2. PDF approves 
the QoS Commit 



3. DEC 



4. GGSN opens the 
gates 



5. RPT 



6. 200 OK 



P-CSCF receives the 200 OK message complying with the conditions specified in the paragraphs above. 

PDF approves the QoS Commit. 

PDF sends COPS DEC message(s) to the GGSN to open the "gates" e.g. enable the use of the authorised 

OoS resources. 

GGSN receives the COPS DEC message(s) and opens the "gates" e.g. enables the use of the authorised 

OoS resources. 

GGSN sends COPS RPT message(s) back to the PDF. 

P-CSCF forwards the 200 OK message. 

Figure 6.1 : Approval of QoS Commit to both the Mobile Originating (MO) side 
and the Mobile Terminating (MT) side 



6.2 



Removal of QoS commit 



The "Removal of QoS commit" procedure is used e.g. when media IP flow(s) of a session is put on hold. (e.g. in case of 
a media re-negotiation or call hold). The PDF decision of "Removal of QoS commit" shall be sent as a separate decision 
to the GGSN corresponding to the previous "Authorize QoS Resources" request. 

6.2.1 Removal of QoS commit at IVIedia on Hold 

Media is placed on hold as specified in RFC 3264 [11]. 

If a bidirectional media component is placed on hold by making it unidirectional, the QoS Commit shall only be 
removed in the deactivated direction. 

Figure 6.2.1 presents the "Removal of QoS commit" procedure at media on hold to both the Mobile Originating (MO) 
side and the Mobile Terminating (MT) side. 
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GGSN 



P-CSCF 
PDF 



2. SDP answer putting 
media on hold 



1 . SDP answer putting 
media on hold 



3. PDF removes the 

QoS Commit for 

IVIedia on hold 



4. DEC 



5. GGSN closes the 
related gates 



6. RPT 



P-CSCF receives an SDP answer putting media on hold within a SIP message. (NOTE 1) 

P-CSCF forwards an SDP answer putting media on hold within a SIP message. 

PDF removes the QoS commit for the media on hold. 

PDF sends COPS DEC message(s) to the GGSN to close the relevant media IP flow gate(s), leaving the 

possible related RTCP gate(s) open to keep the connection alive. 

GGSN receives the COPS DEC message(s) and closes the requested gate(s). 

GGSN sends COPS RPT message(s) back to the PDF. 



NOTE 1 : This procedure occurs whenever a bidirectional media is made unidirectional. 

Figure 6.2.1 : Removal of QoS commit at Media on Hold to both the Mobile Originating (MO) side 

and the Mobile Terminating (MI) side 

6.2.2 Removal of QoS commit at media component removal 

Figure 6.2.2 presents the "Removal of QoS commit" procedure at media component removal for both the Mobile 
Originating (MO) side and the Mobile Terminating (MT) side. The removal of QoS commit is optional. In addition, the 
procedure in Clause 6.3.1 applies in this situation after timer expiry. 
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P-CSCF 
PDF 



2. SDP answer 
removing media 
component 



1 . SDP answer 
removing media 
component 



3. PDF shall start timer 
and may remove the 
QoS Commit for the 
Vrnedia component 



4. DEC 



r 

5. GGSN closes the 
related gates 



6. RPT 



P-CSCF receives an SDP answer removing media component. 

P-CSCF forwards the SDP answer removing media component. 

PDF shall start timer and may remove the QoS commit for the related IP flow{s) of the media component. 

After timer expiry, Figure 6.3.1 applies starting with step 4. 

PDF sends a COPS DEC message to the GGSN to close the related "gate(s)". 

GGSN receives the COPS DEC message and closes the "gate{s)". 

GGSN sends a COPS RPT message back to the PDF. 



Figure 6.2.2: Removal of QoS commit at media component removal for both the Mobile Originating 

(MO) side and the Mobile Terminating (MT) side 



6.3 



Revoke authorization for GPRS an(d IP resources 



The "Revoke Authorization for GPRS and IP resources" procedure is used e.g. upon session release or upon session 
redirection or SIP final error response initiated after bearer establishment. The PDF decision of "Revoke Authorization 
for UMTS and IP Resources" shall be sent as a separate decision to the GGSN corresponding to the previous "Authorize 
QoS Resources" request. 

6.3.1 Mobile initiated session release / Network initiated session release 

Figure 6.3.1 presents the "Revoke Authorization for UMTS and IP Resources" at Mobile initiated session release or 
Network initiated session release for both the Mobile Originating (MO) side and the Mobile Terminating (MT) side. 
The session release may be signalled by a SIP BYE message, by a SIP CANCEL request, or any SIP 3xx redirect 
response, or any 4xx, 5xx, or 6xx SIP final error response. In addition, the revoke authorization for GPRS and IP 
resources applies after timer expiry at the removal of media component(s) from an IMS session which has not been 
released. 
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GGSN 



P-CSCF 
PDF 



_2. BYE, CANCEL, 
3xx, 4xx, 5xx, 6xx 



1. BYE, CANCEL, 3xx, 
4xx, 5xx, 6xx 



3. PDF starts timer 



4. timer expires. PDF removes 
the authorization for the 
affected IPflow{s) 



5. DEC 



6. GGSN disables 
the authorization 



7. PDP context 
Deactivation 



8. RPT 



9. DRQ 



A SIP BYE message, a SIP CANCEL request, a SIP 3xx redirect response, or any 4xx, 5xx, or 6xx SIP 

final error response is received by the P-CSCF. 

P-CSCF forwards the BYE message, or the SIP 3xx redirect response, a SIP CANCEL request, or any 

4xx, 5xx, or 6xx SIP final error response. 

PDF starts timer. 

The timer expires but the PDF has not been notified that the affected PDP context{s) have been modified 

or deactivated. PDF removes the authorisation for the affected IP flow(s) of this session, which it 

authorized previously. 

If step 4 occurs, PDF sends COPS DEC message{s) to the GGSN including client handle{s), which 

identifies the PDP context{s) to be deactivated. 

GGSN receives the COPS DEC message, and disables the use of the authorized QoS resources. 

GGSN initiates deactivation of the PDP context(s) used for the IP multimedia session, in case the UE has 

not done it before. 

GGSN sends COPS RPT message(s) back to the PDF. 

GGSN sends COPS DRQ message(s) to the PDF. 

Figure 6.3.1 : Revoke authorization for GPRS and IP resources - 

at Mobile initiated session release or Network initiated session release 

for both Mobile Originating (MO) and Mobile termination side 



6.4 



Indication of PDP Context Release 



The "Indication of PDP Context Release" procedure is used upon the release of a PDP Context that was established 
based on authorisation from the PDF. 

Figure 6.4.1 presents the "Indication of PDP Context Release" to both the Mobile Originating (MO) side and the Mobile 
Terminating (MT) side. 
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SGSN 



GGSN 



_1. Delete PDP 
context request 



4. Delete PDP 
context response 



P-GSGF 
PDF 



2. DRQ 



3. PDF may remove 
the authorization for 
the corresponding 
media components 



1 . SGSN deactivates the PDP context carrying IP flow(s) of media component(s) by sending the Delete PDP 
Context Request message to the GGSN. 

2. GGSN sends a COPS DRQ message to the P-CSCF(PDF). 

3. P-CSCF(PDF) receives the COPS DRO message and PDF may remove the authorization for the media 
component(s) with the client handle corresponding to that PDP context. 

4. GGSN sends the Delete PDP Context Response message to the SGSN to acknowledge the PDP context 
deletion. 

NOTE: Step 4 may also occur at the same time or before Step 3. 

Figure 6.4.1 : Indication of PDP Context Release to both the Mobile Originating (MO) side 

and the Mobile Terminating (MT) side 

Figure 6.4.2 presents the case when the GGSN initiates the release of a PDP context, i.e. after an error condition has 
been detected in GGSN. 



SGSN 



GGSN 



2. Delete PDP 
context request 



3. Delete PDP 
context response 



P-GSCF 
PDF 



1.DRQ 



4. PDF may remove 
the authorization for 
V ^he media component(sj y 



1 . GGSN sends a COPS DRQ message to the P-CSCF(PDF). 

2. GGSN deactivates the PDP context carrying IP flow(s) of media component(s) by sending the Delete PDP 
Context Request message to the SGSN. 

3. SGSN sends the Delete PDP Context Response message to the GGSN to acknowledge the PDP context 
deletion. 

4. P-CSCF(PDF) receives the COPS DRO message and PDF may remove the authorization for the media 
component(s) authorized for this client handle. 

NOTE: Step 4 may also occur at the same time or before Step 2 and Step 3. 

Figure 6.4.2: Indication of GGSN-initiated PDP Context Release to both 
the Mobile Originating (MO) side and the Mobile Terminating (MT) side 
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6.5 



Modification of PDP Context 



The "Modification of PDP Context" procedure is used when a PDP Context is modified such that the requested QoS 
falls outside of the limits that were authorized at PDP context activation (or last modification) or such that the 
maximum bit rate (downlink and uplink) is downgraded to kbit/s. In these cases, the GGSN communicates with the 
PDF as described below. 

6.5.1 Authorization of PDP Context Modification 

Figure 6.5.1 presents the "Modification of PDP Context" procedure to both the Mobile Originating (MO) side and the 
Mobile Terminating (MT) side when the UMTS QoS which were authorized at PDP context activation (or last 
modification) has been changed by UE. 



SGSN 



GGSN 



1 . Update PDP _ 
Context Request 



c 



P-CSGF 
PDF 



■ 2. COPS REQ 



3. Process 
resource 
request 



-4. COPS DEC 



5. Policy 
Enforcement 



7. Update PDP 
Context Response 



-6. COPSRPT 



1 . A request to modify the PDP context carrying the IP flows of media component(s), of which at least one 
may have been modified or removed, is indicated by sending the Update PDP Context Request message 
to the GGSN with the changed UMTS QoS parameters. 

2. If the GGSN supports a Local Policy Decision Point(LPDP), it can consult the local policy decision stored 
in the LPDP before sending the COPS REQ message to the PDF. In case the requested QoS is within the 
already authorized QoS and the binding information is not changed, the GGSN does not need to send an 
authorization request to the PDF and proceeds to step 5. Otherwise, the GGSN sends a COPS REQ 
message to the PDF. 

3. The PDF receives the COPS REQ message and performs an authorization decision according to the 
requested modification. 

4. The decision taken by the PDF is returned via the COPS DEC message. The DEC message includes the 
policy information to be used by the GGSN in order to perform the policy-based admission control. 

5. The GGSN enforces the policy decision based on the authorization information cached on the GGSN 
LPDP or received from the PDF for the IP flows of media component(s) carried by the PDP context. 

6. The GGSN sends COPS RPT message back to the PDF and reports its success or failure in carrying out 
the PDF decision and notifies state changes if any. 

7. The Update PDP Context Response message is sent to the SGSN to acknowledge the PDP context 
modification. 

Figure 6.5.1 : Authorization of PDP Context IVIodification to both the IVIobile Originating (IVIO) side 

and the lUlobile Terminating (IVIT) side 

6.5.2 Indication of PDP Context Modification 

Figure 6.5.2 presents the "Indication of PDP Context Modification" procedure to both the Mobile Originating (MO) 
side and the Mobile Terminating (MT) side when the maximum bit rate (downlink and uplink) for the PDP context is 
modified to and from kbit/s. 
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SGSN 



GGSN 



1 . Update PDP _ 
Context Request 



4. Update PDP 
Context Response 



P-CSCF 
PDF 



-2. COPSRPT 



('Z. PDF shall forward^ 

the Indication to 

the P-CSCF 



1 . SGSN modifies the PDP context carrying the IP flows of media component(s) by sending the Update PDP 
Context Request message to the GGSN. 

2. GGSN sends a COPS RPT message to the PDF notifying the PDP context modification. 

3. PDF receives the COPS RPT message and forwards the indication to the P-CSCF. 

At this point the authorization may be kept or removed depending on operators policies. 

4. GGSN sends the Update PDP Context Response message to the SGSN to acknowledge the PDP context 
modification. 

NOTE: Step 4 may also occur at the same time or before Step 3. 

Figure 6.5.2: Indication of PDP Context Modification to both the Mobile Originating (MO) side 

and the Mobile Terminating (MT) side 
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6.6 



Session modification initiated SBLP authorization decision 



The GGSN receives an unsolicited authorization decision from the PDF, when a session is modified without adding or 
removing media hues (refer to 3GPP TS 29.207 [7]). The authorization update operation through the Go interface, 
described in figure 6.6, is identical in the originating and terminating cases. If the existing QoS of the PDP context 
exceeds the updated authorised QoS and the UE does not modify the PDP context accordingly, the GGSN shall perform 
a network initiated PDP context modification to reduce the QoS to the authorised level (as shown with the dash arrows 
in the figure). 



GGSN 



P-CSCF 
PDF 



1. DEC 



2. QoS authorisation 

Update. 

Start of timer. 



3. PDP Context update 



4. RPT 



1 . The PDF sends a COPS DEC message to the GGSN to indicate the change of the authorised QoS 
resources (e.g. bandwidth or port numbers). 

2. The GGSN updates the QoS authorization information of the session and starts a timer to supervise the 
PDP context update. 

3. If the existing QoS of the PDP context exceeds the updated authorised QoS and the UE does not modify 
the PDP context accordingly, the GGSN sends an Update PDP Context Request message to the SGSN 
after the expiry of the timer. 

4. The GGSN sends a COPS RPT message back to the PDF. 

Figure 6.6: Authorization update upon session modification without adding or removing media lines 



7 QoS parameter mapping 

7.1 QoS parameter mapping between IIVIS and GPRS 

Within the IMS, session establishment and modification involves an end-to-end message-exchange using SIP/SDP with 
negotiation of media attributes (e.g. Codecs) as defined in 3GPP TS 24.229 [3] and 3GPP TS 24.228 [2]. If the IMS 
apphes Service Based Local Policy (SBLP), as specified in 3GPP TS 29.207 [7], then the P-CSCF shall forward the 
relevant SDP information to the PDF together with an indication of the originator. The PDF notes and authorises the IP 
flows of the chosen media components by mapping from SDP parameters to Authorized IP QoS parameters for transfer 
to the GGSN via the Go interface. The GGSN will map from the Authorized IP QoS parameters to the Authorized 
UMTS QoS parameters. The SIP/SDP message will also have been passed on to the UE, where the UE will perform its 
own mapping from the SDP parameters and application demands to some UMTS QoS Parameters in order to populate 
the requested QoS field within the PDP context activation or modification. If SBLP is applied, i.e. the UE has received 
an authorization token, then the UE should also derive the Authorized UMTS QoS parameters from the SDP 
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parameters. If the UE contains an IP BS manager IP QoS parameters are also generated. Upon receiving the PDP 
context activation or modification, the GGSN shall compare the UMTS QoS parameters against the Authorized UMTS 
QoS parameters. If the request lies within the limits authorised by the PDF, the PDP context activation or modification 
shall be accepted. 

Figure 7.1 indicates the network entities where QoS mapping functionality is required. This mapping is performed by: 

1 . If SBLP is applied then the PDF maps from the SDP parameters determined from the SIP signalling to the 
Authorized IP QoS parameters that shall be passed to the GGSN via the Go interface. The mapping is performed 
for each flow identifier. Upon a request from the GGSN, the PDF combines per direction the individual 
Authorised IP QoS parameters per flow identifier that are identified by the binding information (see clause 
7.1.1). 

2. The UE maps from the SDP parameters to IP QoS parameters (if an IP BS manager is present) and to UMTS 
QoS parameters. This mapping is performed for each flow identifier. The IP and UMTS QoS parameters should 
be generated according to application demands and recommendations for conversational (3GPP TS 26.236 [6]) 
or streaming applications (3GPP TS 26.234 [5]) (see clause 7.2.1). If SBLP is applied, i.e. the UE has received 
an authorization token, then the mapping rules for the authorised QoS parameters should be taken into 
consideration because they define the maximum values for the different requested bit rates and traffic classes 
(see clause 7.2.2). In case the UE multiplexes several IP flows onto the same PDP context, it has to combine 
their IP and UMTS QoS parameters. If an IP BS manager is present, the Translation/Mapping function maps the 
IP QoS parameters to the corresponding UMTS QoS parameters. 

3 The GGSN maps from the Authorized IP QoS parameters received from PDF to the Authorized UMTS QoS 

parameters (see clause 7.1.2). 

4 The GGSN compares then the UMTS QoS parameters of the PDP context against the Authorized UMTS QoS 
parameters (see clause 7.1.3). 

The mapping that takes place in the UE and the network shall be compatible in order to ensure that the GGSN will be 
able to correctly authorise the session. 



2)UE 



Application 



IP BS Manager 



Translation / 
Mapping 



UMTS BS 
Manager 



PDP 

Context 



SDP 



GGSN 



IP BS Manager 
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3) Translation / 
Mapping 



4) UMTS BS 
Manager 



Go 



P-CSCF 



1)PDF 

(Policy 
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NOTE 1 : If SBLP is applied then SDP parameters to Authorized IP QoS parameters mapping. 

NOTE 2: SDP parameters to (IP QoS parameters and) requested UMTS OoS parameters mapping and, if SBLP is 

applied, also SDP parameters to Authorized UIVITS QoS parameters mapping. 
NOTE 3: Authorized IP QoS parameters to Authorized UIVITS QoS parameters mapping. 
NOTE 4: UMTS OoS parameters with Authorized UMTS OoS parameters comparison. 

Figure 7.1 : Framework for QoS mapping between IIVIS and GPRS 
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7.1 .1 SDP parameters to Authorized IP QoS parameters mapping in PDF 

The QoS authorization is to be based on the parameters Maximum Authorized QoS Class and Maximum Authorized 
Data Rate UL/DL. 

When a session is initiated or modified the PDF shall use the mapping rules in table 7.1.1.1 to derive the Authorized IP 
QoS parameters Maximum Authorized Data Rate DL/UL and the Maximum Authorized QoS Class from the SDP 
Parameters. In the case of forking, the various forked responses may have different QoS requirements for the IP flows 
of the same media component. Each Authorized IP QoS Parameter shall be set to the highest value requested for the IP 
flow(s) of that media component by any of the active forked responses. These values are derived by the rules in table 
7.1.1.1 
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Table 7.1.1.1 : Rules for derivation of the lUlaximum Authorized Data Rates 
and IVIaximum Authorized QoS Class per flow identifier in the PDF 



Authorized IP QoS 

Parameter per flow 

identifier 



Derivation from SDP Parameters 
(see note 4) 



IVIaximum Authorized Data 
Rate DL (l\/lax_DR_DL) and 
UL (l\/lax_DR_UL) per flow 
identifier (see note 5) 



I- 



Direction of the IP flow(s) identified by the flow identifier */ 



IF a=recvonly THEN 

IF <SDP direction> = mobile originated THEN 

Direction;= downlink; 
ELSE /* mobile terminated */ 

Direction;= uplink; 
ENDIF; 
ELSE 

IF a=sendonly THEN 

IF <SDP direction> = mobile originated THEN 

Direction; = uplink; 
ELSE /* mobile terminated */ 

Direction;= downlink; 
ENDIF; 
ELSE /*sendrecv, inactive or no direction attribute*/ 

Direction; =both; 
ENDIF; 
ENDIF; 
/* Max_DR_UL and Max_DR_DL */ 

IF media IP flow(s) THEN 

IF bAs=AS; <bandwidth> is present THEN 
IF Direction=downlink THEN 
Max_DR_UL;= 0; 
Ma x_D R_D L ; = bAs ; 
ELSE 

IF Direction=uplink THEN 
Max_DR_UL;= bas; 
Max_DR_DL;= 0; 
ELSE /*Direction=both*/ 
Max_DR_UL;= bas; 
Ma x_D R_D L ; = bas ; 
ENDIF; 
ENDIF; 
ELSE 

bw;= as set by the operator; 
IF Direction=downlink THEN 
Max_DR_UL;= 0; 
Max_DR_DL;= bw; 
ELSE 

IF Direction=uplink THEN 
Max_DR_UL;= bw; 
Max_DR_DL;= 0; 
ELSE /*Direction=both*/ 
Max_DR_UL;= bw; 
Max_DR_DL;= bw; 
ENDIF; 
ENDIF; 
ENDIF; 
ELSE /* RTCP IP flow(s) */ 

IF bRs=RS; <bandwidth> and bRR=RR; <bandwidth> is present THEN 
Max_DR_UL;= (bRs + bsR) / 1000; 
Max_DR_DL;= (bRs + bsR) / 1000; 
ELSE 

IF bAs=AS; <bandwidth> is present THEN 

IF bRs=RS ; <bandwidth> is present and bRR=RR; <bandwidth> is not 
present THEN 

Max_DR_UL;= MAX[0.05 * bas, bRs / 1000]; 
Max_DR_DL;= MAX[0.05 * bas, bRs / 1000]; 
ENDIF; 

IF bRs=RS ; <bandwidth> is not present and bRR=RR; <bandwidth> is 
present THEN 

Max_DR_UL;= MAX[0.05 * bas, bRR / 1000]; 
Max_DR_DL;= MAX[0.05 * bas, bRR/ 1000]; 
ENDIF; 

IF bRs=RS; <bandwidth> and bRR=RR; <bandwidth> is not present THEN 
Max_DR_UL;= 0.05 * bas; 
Max_DR_DL;= 0.05 * bas; 
ENDIF; 
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ELSE 

Max_DR_UL : 
Max_DR_DL: 
ENDIF; 
ENDIF; 
ENDIF; 



as set by the operator; 
as set by the operator; 



Maximum Authorized QoS 

Class [MaxClass] per flow 

identifier 

(see notes 1 , 2 and 3) 



IF (all media IP flows of media type 'audio' or 'video' for the session 

are unidirectional and have the same direction) THEN 

MaxClassDerivation ; =B; /"^streaming*/ 

ELSE 

MaxClassDerivation ; =A; /* conversational*/ 

ENDIF; 



= MaxClassDerivation 

= MaxClassDerivation 

=A; /"^conversational*/ 

=E; /^interactive with priority 3*/ 

=C; /^interactive with priority 1*/ 

/*new media type*/ 
=F; /*background*/ 



CASE <media> 


OF 




' audio ' : 




MaxClass 


' video ' : 




MaxClass 


' application ' ; 


MaxClass 


' data ' : 




MaxClass 


' control ' 




MaxClass 


OTHERWISE 




MaxClass 


END; 







NOTE 1 : The Maximum Authorized QoS Class for a RTCP IP flow is the same as for the corresponding RTP media IP 

flow. 
NOTE 2: When audio or video IP flow (s) are removed from a session, the parameter MaxClassDerivation shall keep the 

originally assigned value. 
NOTE 3: When audio or video IP flow(s) are added to a session, the PDF shall derive the parameter MaxClassDerivation 

taking into account the already existing media IP flow(s) within the session. 
NOTE 4: The SDP parameters are described in RFC 2327 [9]. 
NOTE 5: The "b=RS:" and "b=RR:" SDP bandwidth modifiers are defined in RFC 3556 [10]. 



The PDF shall per ongoing session store the Authorized IP QoS parameters per flow identifier. 

When the GGSN requests the Authorized UMTS QoS parameters for an activated/modified PDF Context carrying IP 
flows of media component(s), the PDF shall use the rules in table 7.1.1.2 to calculate the Authorized IP QoS parameters 
per Client Handle. 

Table 7.1.1.2: Rules for calculating the Maximum Authorized Data Rates 
and Maximum Authorized QoS Class per Client Handle in the PDF 



Authorized IP 

QoS Parameter 

per Client 

Handle 


Calculation Rule 


Maximum 
Authorized Data 
Rate DL and UL 
per Client 
Handle 


Maximum Authorized Data Rate DL/UL per Client Handle is the sum of all Maximum 
Authorized Data Rate DL/UL for all the flow identifiers associated with that 
Client Handle. 

IF Maximum Authorized Data Rate DL/UL per Client Handle > 16000 kbps THEN 

Maximum Authorized Data Rate DL/UL per Client Handle = 16000 kbps /* See 
3GPP TS 23.107 [8] */ 

END; 


Maximum 
Authorized QoS 
Class per Client 
Handle 


Maximum Authorized QoS Class per Client Handle = MAX [Maximum Authorized QoS 
Class per flow identifier among all the flow identifiers associated with that 
Client Handle. 

(The MAX function ranks the possible Maximum Authorized QoS Class values as 
follows: "A" > "B" > "C" > 'D' > 'E' > "F") /* See 3GPP TS 29.207 [7]) */ 
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7.1 .2 Authorized IP QoS parameters to Authorized UMTS QoS 
parameters mapping in GGSN 

The Translation/Mapping function in the GGSN shall derive the Authorized UMTS QoS parameters from the 
Authorized IP QoS parameters received from the PDF according to the rules in table 7. 1.2. 

Table 7.1.2: Rules for derivation of the Authorized UMTS QoS Parameters per PDP context 
from the Authorized IP QoS Parameters per Client Handle in GGSN 



Authorized 

UIMTS QoS 

Parameter per 

PDP context 



Derivation from Authorized IP QoS Parameters 



IVIaximum 
Authorized 
Bandwidth DL 
and UL per PDP 
context 



Maximum Authorized Bandwidth DL/UL per PDP context = Maximum Authorized Data 
Rate DL/UL per CLient Handle 



IVIaximum 
Authorized 
Traffic Class per 
PDP context 



IF Maximum Authorized QoS Class = "A" THEN 

Maximum Authorized Traffic Class = "Conversational" 

ELSEIF Maximum Authorized QoS Class = "B" THEN 

Maximum Authorized Traffic Class = "Streaming" 

ELSEIF Maximum Authorized QoS Class = "C" THEN 

Maximum Authorized Traffic Class = "Interactive"; 
Maximum Authorized Traffic Handling Priority = "1"; 

ELSEIF Maximum Authorized QoS Class = "D" THEN 

Maximum Authorized Traffic Class = "Interactive"; 
Maximum Authorized Traffic Handling Priority = "2"; 

ELSEIF Maximum Authorized QoS Class = "E" THEN 

Maximum Authorized Traffic Class = "Interactive"; 
Maximum Authorized Traffic Handling Priority = "3"; 

ELSE Maximum Authorized Traffic Class = "Background" 
ENDIF ; 



7.1 .3 Comparing UMTS QoS Parameters against the Authorized UMTS 
QoS parameters in GGSN 

Upon receiving a PDP context activation containing binding information, the GGSN requests the Authorized QoS 
information from the PDF, and may request the Authorized UMTS information if a PDP context containing binding 
information is modified (see 3GPP TS 29.207 [7] for details). The GGSN compares the requested UMTS QoS 
parameters against the corresponding Authorized UMTS QoS parameters received via the translation/mapping function. 
If all the requested parameters lie within the limits, the PDP context activation or modification shall be accepted. I.e. the 
following criteria shall be fulfilled: 

• the requested Guaranteed Bitrate DL/UL (if the requested Traffic Class is Conversational or Streaming) or 
Maximum Bitrate DL/UL (if the requested Traffic Class is Interactive or Background) is less than or equal to 
Maximum Authorized data rate DL/UL; and 

• the requested Traffic Class is less than or equal to Maximum Authorized Traffic Class. 

If any of the requested parameters do not lie within their respective limit, the GGSN shall downgrade the requested 
UMTS QoS parameters. 

7.2 QoS parameter mapping in tine UE 

Figure 7.2 indicates the entities participating in the generation of the requested QoS parameters when activate or modify 
a PDP Context in the UE. The steps are: 
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1. The Application provides the UMTS BS Manager, possibly via the IP BS Manager and the Translation/Mapping 
function, with relevant information to perform step 2 or step 4. (Not subject to standardization within 3GPP). 

2. If needed, information from step 1 is used to access a proper set of UMTS QoS Parameters. See 

3GPP TS 26.236 [6] for Conversational Codec AppUcations and 3GPP TS 26.234 [5] for Streaming Codec 
Applications. 

3. If SDP is available then the SDP Parameters should give guidance for the UMTS BS Manager (possibly via the 
IP Manager and the Translation/Mapping function) , according to the rules in clause 7.2.1, to set the Maximum 
Bitrate UL/DL and the Guaranteed Bitrate UL/DL. Furthermore if the SDP Parameters are received in an IMS 
context in which SBLP is applied, i.e. an authorization token has been received, the Maximum Authorized 
Bandwidth UL/DL and Maximum Authorised Traffic Class should be derived according to the rules in clause 
7.2.2. 

4. A set of UMTS QoS Parameters values from step 2 (or directly from step 1) is possibly merged together with the 
Maximum Bitrate UL/DL and the Guaranteed Bitrate UL/DL from step 3. The result should constitute the 
requested UMTS QoS Parameters. If the PDP Context is activated or modified in an IMS context in which SBLP 
is applied, the UE should check that the requested Guaranteed Bitrate UL/DL or requested Maximum Bitrate 
UL/DL (depending on the requested Traffic Class) does not exceed the Maximum Authorized Bandwidth 
UL/DL derived in step 3. Furthermore, if the UE has implemented the mapping rule for Maximum Authorized 
Traffic Class, as defined in clause 7.2.2, the UE should check that the requested Traffic Class does not exceed 
the Maximum Authorised Traffic Class derived in step 3. 
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Figure 7.2: Framework for generating requested QoS parameters in tiie UE 
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7.2.1 SDP to UMTS QoS parameter mapping in UE 

If SDP Parameters are available, then before activating or modifying a PDP Context the UE should check if the SDP 
Parameters give guidance for setting the requested UMTS QoS Parameters. The UE should use the mapping rule in 
table 7.2.1 to derive the Maximum and Guaranteed Bitrate DL/UL from the SDP Parameters. 

Table 7.2.1 : Recommended rules for derivation of the requested Maximum 
and Guaranteed Bitrate DL/UL per media component in the UE 



UMTS QoS Parameter per 
media component 


Derivation from SDP Parameters 


IVIaximum Bitrate DL/UL 

and 

Guaranteed Bitrate 

DL/UL per media 

component 


/* Check if the media use codec (s) */ 

IF [ (<media> = ("audio" or "video")) and (<transport> = "RTP/AVP")] THEN 

/* Check if Streaming */ 

IF a= ("sendonly" or "recvonly") THEN 

Maximum Bitrate DL/UL and Guaranteed Bitrate DL/UL per media 
component as specified in reference [5] ; 
/* Conversational as default !*/ 
ELSE 

Maximum Bitrate DL/UL and Guaranteed Bitrate DL/UL per media 
component as specified in reference [6] ; 
END IF ; 

/* Check for presence of bandwidth attribute for each media component */ 
ELSEIF b=AS :<bandwidth-value> is present THEN 
IF media stream only downlink THEN 

Maximum Bitrate DL = Guaranteed Bitrate DL =<bandwidth>; 
ELSEIF mediastream only uplink THEN 

Maximum Bitrate UL = Guaranteed Bitrate UL =<bandwidth>; 
ELSEIF mediastreams both downlink and uplink THEN 

Maximum Bitrate DL = Guaranteed Bitrate DL =<bandwidth>; 
Maximum Bitrate UL = Guaranteed Bitrate UL =<bandwidth>; 
ENDIF; 
ELSE 

/* SDP do not give any guidance ! */ 

Maximum Bitrate DL/UL and Guaranteed Bitrate DL/UL per media component as 

specified by the UE manufacturer; 

ENDIF ; 



7.2.2 SDP parameters to Autlnorized UMTS QoS parameters mapping in 
UE 

If the PDP Context is activated or modified in an IMS context in which SBLP is applied, i.e. an authorization token has 
been received, then the UE should use the mapping rules in table 7.2.2.1 to derive the Maximum Authorized Bandwidth 
UL/DL per flow identifier. 

Table 7.2.2.1 also has a mapping rule for derivation of Maximum Authorized Traffic Class per flow identifier which 
applies for session initiation and modification. 

In future releases this mapping rule may change. For release 5 this mapping rule is optional for the UE. In the case of 
forking, the various forked responses may have different QoS requirements for the same IP flows of a media 
component. When the Authorized UMTS QoS Parameters are used by the UE, they shall be set equal to the highest 
values requested for the IP flows of that media component by any of the active forked responses. The UE should use the 
mapping rule in table 7.2.2.1 for each forked response. 
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Table 7.2.2.1 : Rules for derivation of the IVIaximum Authorized Bandwidth DL/UL 
and the lUlaximum Authorized Traffic Class per flow identifier in the UE 



Authorized UIVITS QoS 

Parameter per flow 

identifier 



Derivation from SDP Parameters 
(see note 4) 



IVIaximum Authorized 
Bandwidth DL 
(Max_BW_DL) and UL 
(Max_BW_UL) per flow 
identifier (see note 5) 



IF SBLP is applied THEN 

/* The Direction of the IP flow(s) identified by the flow identifier */ 

IF a=recvonly THEN 

IF <SDP direction> = mobile originated THEN 

Direction;= downlink; 
ELSE /* mobile terminated */ 

Direction:= uplink; 
ENDIF; 
ELSE; 

IF a=sendonly THEN 

IF <SDP direction> = mobile originated THEN 

Direction; = uplink; 
ELSE /* mobile terminated */ 

Direction;= downlink; 
ENDIF; 
ELSE /*sendrecv, inactive or no direction attribute*/ 

Direction: =both; 
ENDIF; 
ENDIF; 

/* Max_BW_UL and Max_BW_DL */ 

IF media IP flow(s) THEN 

IF bAs=AS: <bandwidth> is present THEN 
IF Direction=downlink THEN 
Max_BW_UL:= 0; 
Max_BW_D L : = bAs ; 
ELSE 

IF Direction=uplink THEN 
Max_BW_UL:= bas; 
Max_BW_DL:= 0; 
ELSE /*Direction=both*/ 
Max_BW_UL:= bas; 
Max_BW_DL:= bas; 
ENDIF; 
ENDIF; 
ELSE 

bw:= as set by the UE manufacturer; 
IF Direction=downlink THEN 
Max_BW_UL:= 0; 
Max_BW_DL:= bw; 
ELSE 

IF Direction=uplink THEN 
Max_BW_UL:= bw; 
Max_BW_DL:= 0; 
ELSE /*Direction=both*/ 
Max_BW_UL:= bw; 
Max_BW_DL:= bw; 
ENDIF; 
ENDIF; 
ENDIF; 
ELSE /* RTCP IP flow(s) */ 

IF bRs=RS: <bandwidth> and bRE=RR: <bandwidth> is present THEN 
Max_BW_UL:= (bRs + bRR) / 1000; 
Max_BW_DL:= (bRs + bsR) / 1000; 
ELSE 

IF bAs=AS: <bandwidth> is present THEN 

IF bRs=RS ; <bandwidth> is present and bRR=RR; <bandwidth> is not 
present THEN 

Max_BW_UL:= MAX[0.05 * bis, bRs / 1000]; 
Max_BW_DL:= MAX[0.05 * bxs, bRs / 1000]; 
ENDIF; 

IF bRs=RS ; <bandwidth> is not present and bRR=RR; <bandwidth> is 
present THEN 

Max_BW_UL:= I»X[0.05 * bis, bRR / 1000]; 
Max_BW_DL:= 1^1AX[0.05 * bas, Wr / 1000]; 
ENDIF; 

IF bRs=RS: <bandwidth> and bRR=RR: <bandwidth> is not present THEN 
Max„BW_UL:= 0.05 * bas; 
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Authorized UIVITS QoS 

Parameter per flow 

identifier 


Derivation from SDP Parameters 
(see note 4) 




Max_BW_DL:= 0.05 * bas; 
ENDIF; 
ELSE 

Max_BW_UL ; = as set by the UE manufacture; 
Max_BW_DL;= as set by the UE manufacture; 
ENDIF; 
ENDIF; 
ENDIF; 

ELSE 

No authorization is done ; 
ENDIF ; 


Maximum Authorized 
Traffic Class 
[MaxTrafficClass] per 
flow identifier (see 
NOTE1,2and3) 


IF SBLP is applied THEN 

IF (all media IP flows of media type 'audio' or 'video' for the 
session are unidirectional and have the same direction) THEN 
MaxService := streaming; 
ELSE 

MaxService : = conversational; 
ENDIF; 

CASE <media> OF 

'audio'; MaxTraf f icClass ; = MaxService; 

'video': MaxTraf ficClass : = MaxService; 

'application' : MaxTraf ficClass : =conversational; 

'data': MaxTraf ficClass : =interactive with priority 3; 

'control': MaxTraf ficClass : =interactive with priority 1; 

/*new media type*/ 

OTHERWISE : MaxTrafficClass : =background; 
END; 
ELSE 

No authorization is done ; 
ENDIF ; 


NOTE 1 : The Maximum Authorized Traffic Class for a RTCP IP flow is the same as for the corresponding RTF media IP 

flow. 
NOTE 2: When audio or video IP flow(s) are removed from a session, the parameter MaxService shall keep the 

originally assigned value. 
NOTE 3: When audio or video IP flow(s) are added to a session, the UE shall derive the parameter IVlaxService taking 

into account the already existing media IP flows within the session 
NOTE 4: The SDP parameters are described in RFC 2327 [9]. 
NOTE 5: The "b=RS:" and "b=RR:" SDP bandwidth modifiers are defined in RFC 3556 [10]. 



The UE should per ongoing session store the Authorized UMTS QoS parameters per flow identifier. 

Before activate or modify a PDP context the UE should check that the requested Guaranteed Bitrate UL/DL (if the 
Traffic Class is Conversational or Streaming) or the requested Maximum Bitrate UL/DL (if the Traffic Class is 
Interactive or Background) does not exceed the Maximum Authorized Bandwidth UL/DL per PDP context (calculated 
according to the rule in table 7.2.2.2). Furthermore, if the rule in table 7.2.2.1 for calculating Traffic Class per flow 
identifier is implemented, the UE should check that the requested UMTS QoS parameter Traffic Class does not exceed 
the Maximum Authorized Traffic Class per PDP context (calculated according to the rule in table 7.2.2.2). 
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Table 7.2.2.2: Rules for calculating the Maximum Authorized Bandwidths 
and IVIaximum Authorized Traffic Class per PDP Context in the UE 



Authorized 

UIMTS QoS 

Parameter per 

PDP Context 



Calculation Rule 



IVIaximum 
Authorized 
Bandwidth DL 
and UL per PDP 
Context 



IF SBLP is applied THEN 

Maximum Authorized Bandwidth DL/UL per PDP Context is the sum of all Maximum 
Authorized Bandwidth DL/UL for all the flow identifiers 
associated with that PDP Context ; 

IF Maximum Authorized Bandwidth DL/UL per PDP Context > 16000 kbps THEN 
Maximum Authorized Bandwidth DL/UL per PDP Context = 16000 kbps 
/* See ref [8] */ 

END; 

ELSE 

No authorization is done ; 
ENDIF ; 



IVIaximum 
Authorized 
Traffic Class per 
PDP Context 



IF SBLP is applied THEN 

Maximum Authorised Traffic Class per PDP Context = MAX [Maximum Authorised 
Traffic Class per flow identifier among all the flow identifiers 
associated with that PDP Context] ; 

ELSE 

No authorization is done ; 
ENDIF ; 

(The MAX function ranks the possible Maximum Authorised Traffic Class values i 
follows; Conversational > Streaming > Interactive with priority 1 > Interacti 
with priority 2 > Interactive with priority 3 > R=^>^^^n"H\ 



as 
ve 



Background) 
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Annex A (informative): 

Examples of deriving the IVIaximum Authorized parameters 

from the SDP parameters 



A.1 Example 1 



The relevant SDP parameters (i.e. from which the Maximum Authorized IP QoS and Maximum UMTS QoS Parameters 
are derived) in the downlink direction are assigned the following values: 

Table A.1.1 : Values of the relevant SDP parameters in example 1. 



v=0 

o=ecsreid 3262464865 3262464868 IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 

s=MM01 

i=Two unidirectional audio and video media and one bidirectional application media 

1=3262377600 3262809600 

m=video 51372 RTP/AVP 31 

c=IN IP6 2001:0646:000A:03A7:02D0:59FF:FE40:2014 

b=AS:128 

b=RR:2300 

b=RS:3000 

a=sendonly 

m=audio 49170 RTP/AVP 

c=IN IP6 2001:0646:000A:03A7:02D0:59FF:FE40:2014 

b=AS:64 

a=sendonly 

m=application 32416 udp wb 

c=IN IP6 2001:0646:000A:03A7:0250:DAFF:FE0E:C6F2 

b=AS:32 

a=landscape 

a=sendrecv 



The IP flows of the session are identified by 5 flow identifiers (see 3GPP TS 29.207 [7] for the definition of a flow 
identifier): 

Flow identifier < 1,1 > identifies the video media IP flows downlink and flow identifier <1,2> identifies the 
RTCP IP flows uplink and downlink associated with the video media IP flows. 

Flow identifier <2,1> identifies the audio media IP flows downlink and flow identifier <2,2> identifies the 
RTCP IP flows uplink and downlink associated with the audio media IP flows. 

Flow identifier <3,1> identifies the application media IP flows uplink and downlink. 

In the PDF, the Maximum Authorized IP QoS parameters per flow identifier are assigned the values, according to table 
7.1.1.1, as shown in table A. 1.2: 
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Table A.1.2: The values of the Maximum Authorized IP QoS parameters per flow identifier as 
calculated by the PDF. 







Flow Identifier 




<1,1> 


<1,2> 


<2,1> 


<2,2> 


<3,1> 


Max_DR_DL 


(kbps) 


128 


5.3 


64 


3.2 


32 


Max_DR_UL 


(kbps) 





5.3 





3.2 


32 


MaxClass 


B 


B 


B 


B 


A 



In the UE, the Maximum Authorized UMTS QoS parameters per flow identifier are assigned the values, according to 
table 7.2.2.1, as shown in table A.1.3: 

Table A.1.3: The values of the Maximum Authorized UMTS QoS parameters per flow identifier as 
calculated by the UE. 







Flow Identifier 




<1,1> 


<1,2> 


<2,1> 


<2,2> 


<3,1> 


Max BW DL 


(kbps) 


128 


5.3 


64 


3.2 


32 


Max BW UL 


(kbps) 





5.3 





3.2 


32 


MaxTrafficClass 


streaming 


streaming 


streaming 


streaming 


conversational 



Each pack of IP flow(s) described by a media component must all be carried on the same PDP context. If the UE 
decides to put each media IP flow(s) and its associated RTCP IP flow on dedicated PDP contexts (three PDP contexts 
are needed!), then the UE will calculate the values of the Maximum Authorized Bandwidths per PDP context and the 
Maximum Traffic Class per PDP context, according to table 7.2.2.2, as shown in table A. 1.4: 

Table A.I. 4: The values of the Maximum Authorized UMTS QoS parameters per PDP Context as 
calculated by the UE. 





PDP context # 




1 


2 


3 


Maximum Authorized Bandwidth DL (kbps) 


133.3 


67.2 


32 


Maximum Authorized Bandwidth UL (kbps) 


5.3 


3.2 


32 


Maximum Authorized Traffic Class 


streaming 


streaming 


conversational 



For each of the three PDP context activation requests the GGSN will assign a Client Handle to the PDP context 
activation request and send an Authorization Request message to the PDF containing the Binding Information received 
in the PDP context activation request message. The PDF calculates the values of the Maximum Authorized Data Rate 
per Client Handle and a Maximum Authorized QoS Class per Client Handle, according to table 7.1.1.2, as shown in 
table A. 1.5: 

Table A.I. 5: The values of the Maximum Authorized IP QoS parameters per Client Handle as 
calculated by the PDF. 





Client Handle corresponding to 
PDP context # 




1 


2 


3 


Maximum Authorized Data Rate DL (kbps) 


133.3 


67.2 


32 


Maximum Authorized Data Rate UL (kbps) 


5.3 


3.2 


32 


Maximum Authorized QoS Class 


B 


B 


A 



For each of the three Client Handles the PDF sends these Maximum Authorized IP QoS parameters per Client Handle in 
an Authorization Decision message to the GGSN. The GGSN derives the values of the Maximum Authorized 
Bandwidths per PDP context and the Maximum Traffic Class per PDP context, according to table 7.1.2, as shown in 
table A. 1.6: 
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Table A.1.6: The values of the Maximum Authorized UIVITS QoS parameters per PDP context as 
calculated by the GGSN. 





PDP context # 




1 


2 


3 


Maximum Authorized Bandwidth DL (kbps) 


133.3 


67.2 


32 


IVIaximum Authorized Bandwidth UL (kbps) 


5.3 


3.2 


32 


IVIaximum Authorized Traffic Class 


streaming 


streaming 


conversational 



A.2 Example 2 



The relevant SDP parameters in the downhnk direction are assigned the following values: 
Table A.2.1 : Values of the relevant SDP parameters in example 2. 



v=0 

o=ecsreid 3262464321 3262464325 IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 

s=MM02 

i=Two unidirectional audio streams described by one media component 

1=3262377600 3262809600 

m=audio 49170/2 RTP/AVP 

c=IN IP6 2001:0646:000A:03A7:02D0:59FF:FE40:2014 

b=AS:64 

b=RR:2000 

b=RS:1000 

a=sendonly 



The IP flows of the session are identified by 4 flow identifiers (see 3GPP TS 29.207 [7] for the definition of a flow 
identifier): 

Flow identifier < 1,1 > identifies the audio media IP flows downlink and flow identifier <1,2> identifies the 
RTCP IP flows uplink and downlink associated with these audio media IP flows. 

Flow identifier <1,3> identifies the other audio media IP flows downlink and flow identifier <1,4> identifies 
the RTCP IP flows uplink and downlink associated with these audio media IP flows. 

The PDF calculates the values of the Maximum Authorized IP QoS parameters per flow identifier, according to table 
7.1.1.1, as shown in table A. 2. 2: 

Table A.2.2: The values of the Maximum Authorized IP QoS parameters per flow identifier as 
calculated by the PDF. 





Flow Identifier 




<1,1> 


<1,2> 


<1,3> 


<1,4> 


l\/lax_DR_DL (kbps) 


64 


3.0 


64 


3.0 


Max_DR_UL (kbps) 





3.0 





3.0 


MaxClass 


B 


B 


B 


B 



The UE calculates the values of the Maximum Authorized UMTS QoS parameters per flow identifier, according to 
table 7.2.2.1, as shown in table A.2. 3: 
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Table A.2.3: The values of the Maximum Authorized UIVITS QoS parameters per flow identifier as 
calculated by the UE. 





Flow Identifier 




<1,1> 


<1,2> 


<1,3> 


<1,4> 


Max BW DL (kbps) 


64 


3.0 


64 


3.0 


Max BW UL (kbps) 





3.0 





3.0 


MaxTrafficClass 


streaming 


streaming 


streaming 


streaming 



As all IP flows are described by the same media component the UE must let all IP flows be carried on one PDP context. 
The UE will calculate the values of the Maximum Authorized Bandwidths per PDP Context and the Maximum Traffic 
Class per PDP Context, according to table 7.2.2.2, as shown in table A.2.4: 

Table A.2.4: The values of the lUlaximum Authorized UIUITS QoS parameters per PDP Context as 
calculated by the UE. 





PDP context # 




1 


Maximum Authorized Bandwidth DL (kbps) 


134.0 


Maximum Authorized Bandwidth UL (kbps) 


6.0 


Maximum Authorized Traffic Class 


streaming 



The PDF calculates the values of the Maximum Authorized Data Rate per Client Handle and the Maximum Authorized 
QoS Class per Client Handle, according to table 7.1.1.2, as shown in table A. 2. 5: 

Table A.2.5: The values of the Maximum Authorized IP QoS parameters per Client Handle as 
calculated by the PDF. 





Client Handle corresponding to PDP 
context # 




1 


Maximum Authorized Data Rate DL (kbps) 


134.0 


Maximum Authorized Data Rate UL (kbps) 


6.0 


Maximum Authorized QoS Class 


B 



The GGSN derives the values of the Maximum Authorized Bandwidths per PDP context and the Traffic Class per PDP 
context, according to table 7.1.2, as shown in table A.2.6: 

Table A.2.6: The values of the Maximum Authorized UMTS QoS parameters per PDP context as 
calculated by the GGSN. 





PDP context # 




1 


Maximum Authorized Bandwidth DL (kbps) 


134.0 


Maximum Authorized Bandwidth UL (kbps) 


6.0 


Maximum Authorized Traffic Class 


streaming 
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Annex B (informative): 
Change history 
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